home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 31
/
Aminet 31 (1999)(Schatztruhe)[!][Jun 1999].iso
/
Aminet
/
dev
/
basic
/
UDP_Chat.readme
< prev
Wrap
Text File
|
1999-05-02
|
6KB
|
110 lines
Short: UDPfuncsV2.3 for Blitz-good for Net games
Author: anton@ww.co.nz (Anton Reinauer)
Uploader: anton@ww.co.nz (Anton Reinauer)
Version: 2.3
Type: dev/basic
Requires: dev/basic/TCP-to-Blitz.lha, WB 2.0+, min 1.5 meg mem.
These are functions to use the UDP protocol for multiplayer internet
games in Blitz2. Also there is a small IRC-like chat program which is a
good Net game communications test-bed. It checks wether packets have
arrived at their destination by using an acknowledgement system, and
resends packets if necessary. Also it can also act as either a Server
or Client. It has full Connect/Disconnect routines- each player is informed
of the new player and starts sending any messages to the new player, as
the communication is still Peer-To-Peer. Players are automatically
disconnected by the Server if they can't be contacted for a certain amount
of time.
There's a few TCP functions as well, like converting an ASCII address to
numerical (long), and vice-versa, getting your local IP address etc. Some
of the log-in and message protocols could be used in TCP games as well.
It has an Arexx port to allow you to automatically connect to other
UDP_Chat programs from AmiComSys- you just have to pass a host address
to UDP_Chat.
UDP is more appropriate for fast action games, like Doom clones,
Xwing clones, or platformers, maze games etc; anything that needs small
lags (ping times), to remain playable over the Internet/LAN.
What's new in V2.3!
Version 2.3 7/3/1999
------------
I've put in the auto-disconnect code, for when a player stops
responding. If a player can't communicate when another player it
tells the server this- then the Server checks this fact and tells all
the players if this is true. This is for the rare case that two
players have a connection to a third, but only one of those players
loses connection to the third one. If the server can communicate with
the player that's thought to be offline, then the player that
initiated the call gets disconnected instead. This is just some
simple security, to stop cheating by getting the other person
disconnected.
I've tidied up the main loop and taken most stuff out of it- most
of the work is now done by the Comms_Housekeeping{} Function. It's
now much easier to slot these functions into your game.
Added the Clear_Player_Arrays Statement to re-initialise a
disconnected player's data.
Fixed some disconnecting bugs, and now Requested_Connection{}
checks wether the host and port are already connected (it was
possible before to let a host log in twice- if you got the timing
wrong!)
Added Security_Warning{} to allow people to have security messages
printed out in their game- you can chose all, medium, or only serious
security warnings.
Some repeated code in Comms_Housekeeping{} and Acknowledge_Packet{}
has been shifted to Resend_Message{}.
Version 2.2 14/11/1998 (internal version- not released)
------------
The disconnect code has been put in, and I tidied up the Decode_Packet
and Requested connection functions (no more passing variables between them
through Global variables- naughty :).
Also I've changed the Packet protocol a bit- all packets now have a
packet number (.l) in the front, wether they need it or not, as it makes
the encoding and decoding of packets much simpler.
Acknowledge_Packet now checks wether the packet number is in correct
bounds to prevent it getting in a loop, if a bad packet is received.
If the Server closes, it sends the #GAME_END message to all players,
if a player closes, it sends #CP_REQ_PLAYER_DISCONNECT with it's player
number to the Server, then the Server informs all the players (including
the one that sent the disconnect message) that the player has quit, then
the player quits when it receives the disconnect message with it's
player number.
Once a Client or Server has started to quit, it will quit after a certain
time-out, even if it doesn't get all the responses it required.
============================= Archive contents =============================
Original Packed Ratio Date Time Name
-------- ------- ----- --------- -------- -------------
22203 8736 60.6% 29-Mar-99 20:23:10 +Lag problems in Net games
267 196 26.5% 29-Mar-99 20:23:10 +Quit_UDP_Chat.rexx
1290 666 48.3% 29-Mar-99 20:23:10 +UDP_Chat.rexx
28052 11293 59.7% 29-Mar-99 21:22:24 +UDP-Examples.guide
3244 1357 58.1% 29-Mar-99 20:23:10 +UDPFuncs.bb2
1246 190 84.7% 29-Mar-99 20:23:10 +UDPFuncs.bb2.xtra
1238 185 85.0% 29-Mar-99 20:23:10 +UDPHeader.bb2.xtra
2096 814 61.1% 29-Mar-99 20:23:10 +net_protocol_header.bb2
2987 1275 57.3% 29-Mar-99 20:23:10 +TCPFuncs.bb
23616 7216 69.4% 29-Mar-99 20:23:10 +UDP_ChatV1.9.asc
3199 1375 57.0% 29-Mar-99 20:23:10 +UDP_Receive.asc
3056 1336 56.2% 29-Mar-99 20:23:10 +UDP_Receive2.asc
588 294 50.0% 29-Mar-99 20:23:10 +UDPHeader.bb2
14715 4624 68.5% 29-Mar-99 20:23:10 +UDP_ChatV1.6.asc
20690 6332 69.3% 29-Mar-99 20:23:10 +UDP_ChatV1.7.asc
24370 7091 70.9% 29-Mar-99 20:23:10 +UDP_ChatV1.8.asc
26872 8282 69.1% 29-Mar-99 20:23:10 +UDP_ChatV2.0.asc
3014 1255 58.3% 29-Mar-99 20:23:10 +UDP_Send.asc
3209 1347 58.0% 29-Mar-99 20:23:10 +UDP_Send2.asc
2588 957 63.0% 29-Mar-99 20:23:10 +net_protocol_header.bb2
1242 218 82.4% 29-Mar-99 20:23:10 +net_protocol_header.bb2.xtra
26870 8282 69.1% 29-Mar-99 20:23:10 +UDP_ChatV2.1.asc
33629 9796 70.8% 29-Mar-99 20:23:10 +UDP_ChatV2.2.asc
39719 11458 71.1% 29-Mar-99 20:23:10 +UDP_ChatV2.3.asc
1242 179 85.5% 29-Mar-99 20:23:10 +UDP_ChatV2.3.bb2.xtra
-------- ------- ----- --------- --------
291242 94754 67.4% 29-Mar-99 22:26:30 25 files